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ABSTRACT 


An  algorithm  to  fuse  redundant  observations  due  to  multiple  sensor  coverage,  in  order  to  reduce 
duplicate  track  information  provided  to  Vessel  Traffic  Services  (VTS)  operator  displays,  is 
reported.  The  algorithm  receives  inputs  from  multiple  sensors  as  long  as  the  basic  decision  criteria 
elements  are  provided.  The  algorithm  is  tested  with  real  data  collected  from  the  VTS  system  at 
Puget  Sound  in  September  1996.  The  results  indicate  that  the  algorithm  correctly  fuses  redundant 
sensor  observations  on  the  same  vessel  resulting  in  a  significant  reduction  in  the  amount  of 
unnecessary  information  presented  to  the  VTS  operator. 
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1.  INTRODUCTION 

At  a  given  Vessel  Traffic  Center  (VTC),  the  sensor  reports  are  plotted  as  tracks’  on  a  display, 
layered  over  raw  radar  video,  which  is  used  by  system  operators  to  provide  advisories  to  vessels 
that  promotes  a  safe  and  efficient  operating  environment.  The  version  of  software  currently 
employed  by  the  Vessel  Traffic  Services  (VTS)  is  not  capable  of  correlating  redundant  reports  on 
the  same  vessel  that  are  provided  by  the  various  sensors  in  the  system.  These  duplicate  tracks, 
which  appear  on  the  VTS  displays,  are  a  significant  system  deficiency  that  detracts  from  an 
operator’s  ability  to  manage  overall  waterway  safety. 

This  report  presents  a  proof-of  concept  algorithm  that  will  perform  multisensor  data  fusion  on 
the  sensor  information  currently  provided  on  vessels  in  a  VTS  System.  The  results  are  output  as  a 
unique  set  of  tracks  to  an  operator  display  and  archived.  The  algorithm  takes  data  from  any 
available  sensor  that  can  provide  the  necessary  attributes  in  order  to  make  a  fusion  decision.  Unlike 
the  previous  work  [Ref  1,  2],  actual  data  from  an  operational  VTS  System  was  obtained  for  testing 
and  development  of  the  algorithm. 

An  introduction  to  the  VTS  environment  and  overall  system  description  is  provided  in  Section 

2.  In  Section  3,  data  collection,  formatting  are  discussed.  The  discussion  of  the  algorithm,  its 
development  and  component  parts  are  found  in  Section  4  while  the  actual  results  are  reported  in 
Section  5.  The  algorithm  is  implemented  using  the  MALAB®  package,  and  a  listing  of  the  code  is 
available  in  [Ref  1]. 

2.  THE  VTS  ENVIRONMENT 

The  VTS  system  is  a  module  of  the  Joint  Maritime  Command  Information  System  (JMCIS). 
The  current  configuration  of  the  VTS  system  is  based  on  the  Unified  Build  (UB)  Software 
Development  Environment  (SDE)  Track  Database  Manager  (Tdbm)  Service  [Ref  2, 3]. 

The  data  is  obtained  from  multiple  sensors:  radar.  Automated  Dependent  Surveillance  (ADS) 
and  synthetic,  and/or  Standard  Routes  (SR).  The  radar  tracks  are  provided  by  commercially 
available  radar  sets.  The  need  for  a  data  fusion  scheme  within  the  VTS  system  has  been  clearly 
identified  for  the  overlapping  radar  coverage  scenario.  ADS  tracks  are  Global  Positioning  System 
(GPS)  or  Differential  GPS  (DGPS)  based  information  sent  automatically  via  radio  link  from  the 
vessel.  It  will  provide  a  greater  reporting  redundancy,  thus  even  more  uncorrelated  tracks  to  the 
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operator  displays.  SR  tracks  based  on  the  last  known  position,  course  and  speed  of  the  vessel  are 
synthetically  generated  within  the  VTS  system  by  operator  intervention.  These  are  available  to  the 
operator  should  the  vessel  in  question  have  a  non-reporting  status  from  any  of  the  system’s  other 
sensors.  The  resulting  quantity  of  redundant  information  continuously  provided  to  operator 
displays  is  a  serious  deficiency  which  the  proposed  fusion  scheme  seeks  to  address. 

The  VTS  system  is,  for  all  practicable  purposes,  JMCIS  with  all  correlation  functions  but  Link 
Correlation  disabled.  The  VTS  system  does  not  use  four  of  the  five  correlation  functions  of  the 
JMCIS  system.  It  is  configured  this  way  to  ensure  that  the  one-to-one  association  between  a  link 
track  and  a  platform  track  is  never  severed.  However,  it  prevents  the  VTS  system  from  being  able 
to  perform  many-to-one  or  redundant  link  track  associations  to  one  platform  track.  The  fusion 
algorithm  proposed  here  will  make  these  many-to-one  associations  as  quickly  and  as  transparently 
as  possible,  allowing  the  operator  to  focus  on  overall  vessel  traffic  management  as  opposed  to 
managing  multiple  incidences  of  the  same  vessel. 

Figure  1  [Ref  2]  is  a  representation  of  the  JMCIS  software  architecture,  and  the  fusion 
algorithm  could  be  introduced  as  a  part  of  the  Correlator.  As  tracks  are  repotted  into  the  Tdbm, 
each  one  is  sent  through  the  Correlator  in  order  to  promote  it  to  an  existing  platform  track  (report 
from  the  same  RSP  with  an  identical  track  number)  or  generate  a  new  platform  track.  At  this  point 
the  fusion  algorithm  would  examine  the  link  tracks  resident  within  the  Tdbm  and  determine 
whether  any  redundancy  in  reporting  had  occurred.  The  algorithm  would  then  output  a  unique  set 
of  platform  tracks  where  one-to-one  (unique  track)  and  many-to-one  (redundant  reports  from 
multiple  sensors  on  the  same  vessel)  promotions  had  been  accomplished. 

2.1  Radar  Tracks 

The  radar  processor  incorporates  a  sliding  window  detection,  algorithm  which  integrates  hit  data 
over  the  antenna  beamwidth.  It  uses  leading  and  trailing  edge  confidence  count  criteria  to  extract 
targets  to  achieve  the  CFAR  (system  default  is  lOE-5)  set  by  the  operator  [Ref  4].  A  Confidence 
Count  (CC)  is  performed  to  determine  if  the  required  number  of  hits  occurred  to  declare  a  valid 
plot.  The  fusion  algorithm  assumes  that  the  system  parameters  have  been  optimized  for  the  current 
operating  conditions  and  that  valid  tracks  are  being  reported  to  the  VTC's  Tdbm.  [Ref.  2] 

The  following  information  is  sent  to  the  Tdbm  from  the  RSP  via  a  microwave  or  fiber  optic 
communications  link  [Ref.  5]:  Site  Number  (Sensor  identification);  Track  Number;  Time  of  Track 
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Position  (UTC);  Course  in  Degrees;  Speed  in  Knots  (KTS);  Predicted  Range  in  Nautical  Miles 
(NM);  Predicted  Azimuth;  Radar  Range  in  NM;  Radar  Azimuth;  Extent  Range  in  NM;  Extent 
Azimuth;  Track  Quality  (low  of  4  to  high  of  9  );  Acquisition  Mode  ( Automatic  -  A,  Manual  -  M); 
Lost  Track  (Set  after  a  predetermined  number  of  Coast  Tracks  have  occurred);  and  Coast  Track 
(Indicates  no  hit  on  last  scan). 

2.2  Automated  Dependent  Surveillance  (ADS)  Tracks 

The  GPS  based  ADS  segment  is  currently  being  integrated  into  the  Vessel  Traffic  Services 
(VTS)  System  Expansion  program  [Ref.  6]  (see  Figure  2).  GPS  Standard  Positioning  Service 
(SPS)  is  a  slightly  degraded  GPS  (accurate  to  100  meters)  signal  available  worldwide  at  no  cost  to 
any  user  who  wants  it.  Differential  GPS  (DGPS)  is  a  USCG  program  to  realize  a  10-meter 
accuracy  from  the  GPS  SPS  by  furnishing  signal  corrections  to  properly  equipped  users  [Ref.  5]. 

The  ADS  segment  will  provide  GPS  and  DGPS  tracking  capability  to  the  VTS  system.  The 
inherent  accuracy  of  GPS  based  systems  [Ref.  5],  their  relatively  low  cost  and  almost  universal 
presence  will  make  ADS  a  key  component  of  the  VTS  system  in  the  near  future.  ADS  information 
is  sent,  from  the  vessel  itself,  to  the  VTC  over  a  satellite  or  Digital  Selective  Calling  (DSC)  data 
link.  The  National  Marine  Electronics  Association  (NMEA)  0183  Standard  is  used  to  report  ADS 


Figure  1.  JMCIS  Software  Architecture 

tracks  into  the  system.  This  "Voiceless  VTS"  data  stream  provides  all  required  information  in  order 
to  build  a  track  history  within  the  Tdbm  [Ref.  4].  The  following  information,  on  ADS  tracks,  is 
available  to  the  fusion  algorithm:  Vessel  Name;  UTC;  Tracking  Status  (e.g..  Radar,  ADS,  SR); 
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Track  ID.  (Track  Number);  Sensor  Track  Number  (e.g.,  Radar  Track  Number  or  SR  Number); 
Course  (True  Course  in  degrees);  Speed  (Knots  Over  the  Ground);  Latitude;  Longitude;  Size 
(Length)  of  Vessel;  and  Track  Quality. 


Sound 


Figure  2.  Proposed  ADS  Segment 

2.3  Standard  Route  (SR)  Tracks 

The  SR  represent  an  Estimated  Position  (EP)  of  the  vessel  of  interest  through  a  VTC’s  Area  of 
Responsibility  (AOR).  SRs  are  generated  by  the  SR  daemon,  and  the  system  can  be  configured  for 
automatic  or  manual  generation.  When  a  radar  track  is  lost  on  a  vessel,  an  SR  is  initiated  to  help 
estimate  the  position  of  the  vessel  as  it  transits  the  AOR.  These  SRs  are  multisegmented  predefined 
routes  that  are  geographically  fixed  to  represent  the  waterway  under  consideration.  These  routes  are 
assigned  based  on  the  type  of  vessel  and  initial  position,  and  vectoring  is  derived  from  the  track 
information  last  reported  into  the  Tdbm.  The  predicted  path  of  the  vessel  is  then  updated  every  ten 
seconds  into  the  Tdbm  and  closely  monitored  and  manually  updated  as  deemed  necessary.  The  SR 
is  terminated  once  the  original  or  another  sensor  acquires  the  track.  There  is  no  association  between 
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radar  and  SR  tracks  and  it  takes  a  great  deal  of  operator  experience  and  intuition  to  generate  a 
reasonable  approximation  of  a  vessel’s  route.  [Ref.  2] 

3.  DATA  COLLECTION,  FORMATTING,  AND  PREPROCESSING 

The  data  used  to  test  the  algorithm  was  collected  over  a  two  day  period,  September  11-12, 
1996,  at  the  Puget  Sound  VTC.  Conditions  for  the  data  collection  were  satisfactory,  and  data  sets 
were  rich  with  multiple  sensors,  primarily  radar  and  ADS,  reporting  on  the  same  target.  Portable 
ADS  equipment  was  set  up  on  selected  Washington  state  ferries  whose  routes  and  schedules  were 
well  known  to  the  VTS  system  operators.  Track  history  recording  was  conducted  in  accordance 
with  [Ref.  7]  and  on  a  non-interference  basis  with  normal  VTC  operations.  Up  to  10  tracks  were 
available  for  simultaneous  track  history  recording  for  up  to  12  hours  in  duration.  All  parameters 
except  Track  Quality  (TC)  were  correctly  reported  into  the  system  and  archived. 

Post  analysis  of  the  data  showed  that  there  was  enough  variety  in  the  scenarios  and  sufficient 
redundancy  in  sensor  reports  to  thoroughly  test  the  fusion  algorithm.  Due  to  the  limited  number  of 
tracks  that  could  be  recorded,  emphasis  was  placed  on  ADS  and  radar  data;  no  SR  track  scenarios 
were  collected.  The  track  histories  were  stored  in  ASCII  files  and  the  data  was  recorded  for  each 


selected  track  in  the  following  format  [Ref.  6]: 


Name;  track-history.dat 

Path:  /h/data/local/ADS 

Format: 

1 

2 

3 

4 

5 

6 

7 

8 

9 

10 

11 

cccc 

cccc 

cccc 

ddmm.mm 

ddmm.mm 

size 

x<CR> 

cccc 

AAA 

cccc 

cccc 

X.X 

ddmm.mm 

ddmm.mm 

size 

x<CR> 

etc. _ _ _ _ _ 

1 

26cc 

Vessel  Name 

2 

DDMMYYhhmmss 

UTC — ^Time  of  Track  Position 

3 

AAA 

Track  Status  (Radar,  SR,  ADS) 

4 

cccc 

Track  ED 

5 

cccc 

Sensor  Track  # — Radar  #  and  Track  #  or  CID  #  or  SR  # 

6 

x.x 

True  Course 

7 

x.x 

Speed  (knots  over  ground) 

8 

ddmm.mm 

Latitude — degrees  1  minutes 

9 

ddmm.mm 

Longitude — degrees  1  minutes 

10 

# 

Size  of  Vessel 

11 

X 

Track  Quality  (good,  coast,  lost  for  Radar;  0,  Non-Diff,  Diff  for  ADS) 
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A  sample  of  the  contents  of  a  recorded  track  file  is  shown  below: 

UNK-4743.110996212055, Radar, 742,3, 180.4,5.9,4735.08,-12228.05,0,0 
UNK-4754,110996212055,Radar,753,3,186.6,5.1,4735.54,-12227.82,0,0 
UNK-4773,110996212052,Radar,772,3,93.4,18.0,4736.41,-12228.42,0,0 
SPOKANE_ADS,  1 1 09962 12023,  ADS,773,3669994520, 92.7, 1 8.0,4736.37,- 1 2228.66,0,0 
SPOKANE_ADS,l  10996212056,ADS,773,3669994520,93.2,18.3,4736.36,-12228.41,0,0 
SPOKANE_ADS,110996212056,ADS,773,3669994520,93.2, 18.3,4736.36,-12228.41,0,0 
UNK-4751,110996212058,Radar,750, 3,357.7,8.9,4738.47 ,-12226.49,0,0 
UNK-4756,110996212058,Radar,755,3,195.2,9.2, 4734.51,-12228.03,0,0 
UNK-4773, 1 1 09962 12058, Radar,772,3,9 1 .9, 1 8. 1 ,4736.4 1  ,-12228.38,0,0 

A  vessel’s  name  is  identified  in  column  one  as  unknown  (UNK-XXXX)  if  the  true  identity  has  not 

been  determined.  Column  three  indicates  sensor  type. 

3.1  Preprocessing 

The  data  files  were  recorded  in  ASCII  comma-delimited  format.  The  following  procedure  was 
followed  to  build  data  files:  open  the  ASCII  file  in  the  word  processor  of  choice  [Microsoft  Word® 
in  this  case];  cut  and  paste  the  desired  length  of  data  into  a  new  file,  then  use  the  Save  As  menu 
choice  and  name  the  file  with  a  .dat  extension,  [e.g.,  ll_el.dat];  and  perform  a  global  search  and 
replace  on  Track  Status,  changing  Radar  to  “1,”  ADS  to  “2”  and  SR  to  “3.” 

Once  these  files  were  built,  a  set  of  functions  were  developed  to  read  them  into  MATLAB® 
and  emulate  what  the  data  would  look  like  to  the  fusion  algorithm  within  the  Tdbm.  To  accomplish 
this,  the  data  were  placed  in  a  matrix  called  ObsnMatrix.  The  data  from  the  individual  fields  are 
placed  in  their  respective  storage  vectors.  They  are  then  appended  together  to  form  the  observation 
matrix  ObsnMatrix.  The  contents  of  the  matrix  are  easily  discerned  via  their  descriptive  names. 
ObsnMatrix  =  [Latitude,  Longitude,  TrueCourse,  Speed,  Size,  TracklDNumber,  UTC, 
TrackQuality,  TrackStatus,  SensorTrackNumber].  The  data  is  now  ready  to  be  input  to  the 
fusion  algorithm  as  if  it  were  available  in  real  time. 

4.  FUSION  ALGORITHM 

This  section  examines  the  fusion  algorithm  in  detail  (see  Figure  3)  and  describes  the  fuzzy 
association  techniques  that  are  employed  to  provide  a  possible  solution  to  the  growing  track 
redundancy  problem  within  the  VTS  System.  Data  windowing  (prior  to  the  fusion  algorithm)  and 
multisensor  data  fusion,  in  general  terms,  are  as  well. 
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Figures.  Overview  of  Fusion  Algorithm 


4.1  Windowing  of  Data 

A  time  window  operation  is  applied  to  the  data  once  it  is  made  available  to  the  algorithm  from 
the  Tdbm.  The  windowed  observations  are  placed  in  a  refined  observation  matrix  called 
WindowedObsns  to  await  possible  further  data  set  reduction.  The  actual  length  of  the  window 
depends  strictly  on  update  rates  from  the  various  sensors  and  the  relative  change  in  position  of  a 
track  between  updates.  In  the  case  of  the  VTS  System,  radar  tracks  are  updated  every  six  seconds, 
SR  tracks  every  ten  seconds  and  ADS  tracks  every  15  seconds.  Vessel  speeds  vary  from  zero  to 
twenty  knots  with  the  majority  of  vessels  making  good  around  eight  knots. 

Given  the  relatively  slow  change  of  position  of  the  vessels  and  the  fast  update  rates  of  the 
sensors,  it  is  readily  apparent  that  the  tracks  are  over  sampled  for  this  application.  A  window  size 
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of  15  seconds  would  ensure  an  opportunity  for  all  sensor  types  to  report  thus  addressing  any  latency 
issues  for  the  current  system  configuration.  The  VTS  System  does  not  require  that  positions  be 
updated  this  quickly;  therefore,  it  is  possible  to  substantially  reduce  the  processing  load  by 
optimizing  the  window  size  to  obtain  a  satisfactory  update  rate. 

After  the  window  has  been  applied,  the  algorithm  selects  the  most  recent  track  from 
WindowedObsns  and  places  them  in  a  reduced  observation  matrix  called  MostRecentTrks.  The  data 
set  is  now  reduced  to  the  desired  content  and  can  be  input  to  the  fusion  algorithm. 

4.2  Multisensor  Data  Fusion 

The  primary  goal  of  the  fusion  algorithm  is  to  fuse  together  observations  from  different  sensors 
made  on  the  same  target  or  vessel.  The  reporting  sensor  can  be  of  any  type  as  long  as  it  provides 
the  necessary  information  upon  which  fusion  decisions  are  made.  Here,  reports  are  available  from 
radar,  ADS  and  SR  mechanisms.  Inclusion  of  additional  sensors  (e.g.,  acoustic  sensors  positioned 
in  critical  waterways)  can  be  readily  achieved  in  future  versions  of  the  algorithm.  The  fused  tracks 
are  assigned  a  platform  number  for  output  to  the  operator  displays,  with  the  superior  sensor 
assigned  reporting  responsibility.  The  information  from  inferior  sensors  is  suppressed,  but  not 
decimated,  resulting  in  a  more  clear  picture  of  what  is  occurring  in  the  waterways  and  harbors  via 
operator  displays.  This  fusion  process  is  achieved  through  the  use  of  fuzzy  membership  functions 
that  determine  the  level  of  correlation  between  the  set  of  observations  from  different  sensors. 

The  proposed  algorithm  attempts  to  accomplish  fusion  by  specifying  mles  that  help  in  making 
decisions  [Ref.  8].  The  algorithm  associates  redundant  tracks  for  same  vessel  which  are  reported 
into  the  system  from  the  various  system  sensors.  This  association  is  performed  by  the  membership 
functions  that  measure  the  level  of  similarity  between  a  set  of  observations.  These  values  of 
“sameness”  are  then  used  in  the  fusion  process  for  decision  making  (threshold  setting)  and  track 
identification.  The  output  can  be  visualized  by  taking  a  combination  of  data,  from  different 
sources,  to  obtain  a  refined  location  and  identity  estimation  on  the  target  [Ref.  9]. 

4.3  Positional  Fusion  [Ref.  10] 

The  reporting  sensors  in  the  VTS  System  have  already  performed  positional  or  sensor  level 
fusion  prior  to  initiating  a  report  to  the  Tdbm.  In  the  case  of  radar,  it  is  a  function  of  the  pairing, 
developing  and  maturing  sequence  (see  Section  2);  where  as  for  ADS  and  SR  reports,  it  is 
physically  impossible  to  have  overlapping  coverage  on  a  vessel.  The  VTS  system  assumes  that 
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sensor  level  fusion  is  being  carried  out  correctly  and  only  valid,  non-redundant  tracks  are  being 
generated  and  reported  by  individual  sensors.  [Ref.  2] 

Once  the  valid  tracks  are  in  the  Tdbm,  central  level  positional  fusion  is  carried  out  to  eliminate 
the  redundancies  that  occur  from  different  sensors  reporting  on  the  same  track.  This  is  not  database 
fusion  as  the  algorithm  does  not  destroy  or  alter  any  information  about  a  target  even  though  a  fusion 
decision  may  have  been  made.  The  output  from  the  inferior  redundant  sensors  is  simply  suppressed 
and  not  routed  to  the  displays.  This  approach  was  taken  to  ensure  that  the  system  could  take 
advantage  of  track  redundancy  as  represented  by  the  suppressed  information.  This  suppressed 
information  would  be  utilized  if  the  reporting  sensor  on  a  fused  track  ceases  to  report  and  a  hand  off 
to  the  next  superior  sensor  becomes  necessary.  The  other  obvious  case  is  when  a  decision  is  made 
to  defuse.  Additionally,  having  this  information  available  for  ready  recall  helps  in  the  analysis  of 
the  system  to  ensure  optimum  performance. 

4.4  Fusion  Process 

The  algorithm  (see  Figure  4)  now  takes  the  reduced  data  set  resident  in  the  matrix 
MostRecentTrks  and  begins  the  fusion  process.  It  accomplishes  this  by  sequentially  comparing 
track  pairs  in  order  to  determine  the  grade  of  membership  between  the  attributes  that  are  used  in  the 
fusion  decision  process.  The  attributes  used  in  the  decision  process  are  Latitude,  Longitude,  Course 
and  Speed.  Originally,  vessel  Size  and  TrackQuality  were  to  be  included  but  their  utility  was 
marginalized  by  the  methods  used  to  record  their  values  into  the  system  during  data  collection.  If 
deemed  necessary,  these  or  any  other  suitable  attributes  can  be  readily  added  in  the  future  due  to  the 
modular  approach  used  to  constmct  the  code. 

The  assignment  of  membership  value  that  is  accomplished  by  the  fuzzy  association  system  is  a 
measure  of  similarity  or  sameness  by  correlation  [Ref.  2].  Membership  functions  are  used  to  grade 
the  attributes  of  a  set  usually  in  the  range  [0,1].  The  closer  the  attribute  is  graded  to  the  upper 
bound,  the  higher  the  grade  of  membership.  The  higher  the  grade  the  attribute  is  assigned,  the  more 
similar  it  is  to  the  attribute  it  is  being  compared  against.  Instead  of  answering  the  question  with  a 
crisp  or  simple  YES  or  NO,  it  provides  a  scaled  interpretive  answer  which  can  be  NOT  LIKE,  A 
BIT  LIKE,  SOMEWHAT  UKE,  A  LOT  LIKE,  or  LIKE.  This  type  of  answer  is  obviously  a  better 
representation  of  how  VTS  operators  currently  interpret  about  what  is  developing  on  their  displays. 
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Figure  4.  Row  Chart  of  the  Fusion  Algorithm 

In  the  design  of  a  fuzzy  association  system  the  following  approach  is  used  [Ref.  2, 11]:  ascertain 
the  universe  of  discourse  of  system  input(s)  and  output(s);  design  the  membership  function(s); 
decide  on  the  fuzzy  rule(s)  to  relate  input(s)  and  output(s);  and  devise  the  defuzzifying  technique(s). 

Membership  function  design  is  based  on  the  variations  inherent  in  an  attribute  that  is  being 
compared  [Ref.  2].  Given  that  radar  and  ADS  positional  reports  (i.e.  latitude  and  longitude)  are  for 
the  most  part  dependable  and  accurate,  a  form  of  triangular  membership  function  is  often  used  as 
shown  in  Figure  5.  Where  as  attributes  that  tend  to  be  not  quite  as  accurate  (highly  dependent  on 
the  type  of  sensor),  such  as  speed,  require  a  broadened  roof  as  shown  in  Figure  5,  which  allows  for 
a  greater  range  of  values.  Combinations  of  these  typical  membership  function  shapes  (e.g.. 
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(C) 


Figure  5.  Membership  Functions:  (a)  positional  attributes  -  longitude  and  latitude;  (b) 
course  in  degrees;  and  (c)  speed  in  knots 

trapezoidal)  are  useful,  as  in  the  case  of  the  course  attribute,  where  you  desire  a  generous 
association  within  a  certain  range  but  not  outside  of  a  fixed  range.  Membership  functions  are  by 
their  very  nature  subjective,  but  they  are  far  from  arbitrary  and  need  to  be  based  on  the  application 
and  the  attribute  in  question.  The  relative  shape  of  a  membership  function  is  only  a  starting  point 
and  follow  up  analysis  of  its  performance  is  critical  to  fine  tuning  the  process. 

The  next  step  is  to  evaluate  all  the  attributes  and  their  membership  grade  against  a  threshold 
value.  This  threshold  value  represents  the  known  physical  limitations  or  specifications  of  the 
sensor.  In  the  case  of  a  radar,  it  is  based  on  bearing  resolution,  range  resolution  and  speed  error. 
For  ADS,  it  is  the  relative  accuracy  of  the  measurements  based  on  the  type  of  the  GPS  being  used. 
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With  this  diversity  in  the  relative  accuracy  of  sensor  attributes,  the  threshold  is  always  set  based  on 
the  least  accurate  sensor. 

With  the  thresholds  set,  the  membership  values  of  the  attributes  are  checked  in  the  following 
sequence:  Latitude,  Longitude,  Course  and  Speed.  Each  attribute’s  membership  value  must  exceed 
the  threshold  or  the  association  fails  for  that  track  pair,  and  the  algorithm  proceeds  to  the  next  track 
pair  and  repeats  the  process.  Track  pair  combinations  that  have  all  their  attributes  exceeding  the 
threshold  values  are  defuzzified  and  output  as  a  virtual  binary  T’  as  represented  by  their  presence  in 

a  storage  matrix  called  FusionCandidates  (see  Figure  6). 

Once  the  FusionCandidates  matrix  is  complete,  the  algorithm  then  performs  an  evaluation  to 
determine  what  type  of  sensor  is  reporting  and  its  location.  This  information  is  used  to  assign 
reporting  responsibility  to  the  superior  sensor.  The  current  hierarchy  has  radar  at  the  top  followed 
by  ADS  and  SR  in  order  of  descending  priority.  Radar  is  currently  given  superior  sensor  status  due 


Figure  6.  Depiction  of  the  Fuzzy  Associative  Decision  System 
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to  the  slow  update  rate  of  the  ADS  tracks.  Once  the  update  rates  for  ADS  are  at  least  comparable  to 
radar  update  rates,  ADS  tracks  will  be  assigned  superior  sensor  status. 

Should  the  redundancy  in  reporting  be  a  consequence  of  the  same  type  of  sensor,  it  is  necessary 
to  select  the  superior  of  the  two.  In  the  case  of  radar  tracks  this  is  based  on  the  characteristics  of  the 
radar;  the  radar  possessing  superior  characteristics  (resolution  capabilities)  is  chosen.  If  the  radars 
are  similar,  a  designation  within  the  system  based  on  alternate  criteria,  such  as  current  operating 
performance  and  relative  distance  to  the  target,  would  be  used  to  select  the  superior  sensor.  The 
fusion  algorithm  is  easily  modified  to  accommodate  any  changes  to  sensor  status.  Same-t5q)e 
sensor  redundancy  is  a  radar  issue  exclusively  as  it  is  physically  impossible  to  get  multiple  ADS 
and  SR  tracks  on  the  same  vessel.  At  this  point  the  selected  tracks  that  are  being  reported  on  by  the 
superior  sensors  are  placed  in  a  matrix  called  HitsToKeep,  and  the  tracks  deemed  redundant  are 
placed  in  a  matrix  called  CeaseReport. 

4.5  Report  Generation  and  Output 

At  this  point  it  is  necessary  to  include  the  tracks  that  were  previously  deemed  not  fuseable 
along  with  those  that  have  been  given  reporting  responsibility  for  the  fused  tracks.  HitsToKeep  is 
augmented  with  these  lone  tracks,  and  the  matrix  UpdateReport  contains  all  the  track  numbers  that 
need  to  be  reported  to  the  operator  display. 

The  last  step  that  needs  to  occur  before  updating  the  display  is  to  take  the  track  numbers  from 
UpdateReport  and  extract  all  the  track  data  from  MostRecentTrks  required  for  a  complete  report. 
For  computational  efficiency,  all  unnecessary  data  fields  had  been  purged  during  the  fusion  process. 
UpdateReport  is  then  checked  for  redundancy,  sorted  by  track  number  and  placed  in  the  final  output 
matrix  TrksToPlot.  An  example  of  a  typical  plot  of  information  display  is  depicted  in  Figure  7. 

At  this  point  the  fusion  cycle  is  complete.  The  superior  sensors  have  been  assigned  reporting 
responsibility  for  tracks  that  had  redundant  or  multiple  sensor  reports.  The  reports  deemed 
redundant  have  had  their  output  suppressed,  and  the  system  operator  is  now  seeing  only  single 
realizations  of  vessel  tracks.  The  data  window  is  now  moved  forward  in  time  in  order  to  process 
the  next  set  of  sensor  reports  on  tracks  present  in  the  system.  The  fusion  operation  is  repeated  in 
this  manner  until  it  is  turned  off. 
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5.  RESULTS 

Actual  data  from  an  operational  VTS  system  was  collected  at  Puget  Sound  in  September  1996. 
This  data  allowed  for  thorough  testing  of  the  algorithm  for  a  variety  of  real  life  scenarios  depicting 
the  redundancy  issues  faced  by  system  operators  with  overlapping  information  from  multiple  radar 
and  ADS  tracks. 

In  order  to  build  the  data  sets  for  demonstration,  it  was  necessary  to  load  a  large  amount  of  data 
with  the  fusion  process  turned  off.  The  output  to  the  display  is  a  realization  of  what  was  occurring 
in  the  harbor  and  waterways  during  that  time  period.  The  display  was  then  examined  to  determine 
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Figure  7.  Scenario  Plot  Example:  (a)  no  fusion  applied  and  (b)  fusion  applied 


the  track  numbers  that  were  to  be  extracted  to  build  a  demonstration  of  a  particular  scenario.  Once 
this  procedure  has  been  completed,  the  demonstration  file  is  ready  to  run.  Demonstration  files  are 
easily  modified  in  order  to  examine  time  frames  of  particular  interest.  There  are  many  variables 
within  the  algorithm  that  can  be  displayed  during  execution  that  will  help  determine  what  is 
actually  happening. 

The  algorithm  performed  correctly  under  all  test  scenarios.  The  redundant  tracks  would  stay 
fused  as  long  as  each  track  pair  being  assessed  had  a  data  point  within  the  observation  window. 
There  were  no  problems  associated  with  vessels  that  were  turning  and  the  algorithm  always  selected 
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the  superior  sensor.  The  algorithm  had  no  trouble  dealing  with  a  large  amount  of  tracks  and  or 
interruptions  in  data  streams.  The  following  scenarios  were  considered: 

•  Scenario  1;  Overlapping  radar  coverage  (Tracks  750  and  751)  on  a  single  vessel  along  with 
an  independent  vessel  (757).  Track  751  is  initially  the  superior  sensor  but  drops  track 
causing  reporting  responsibility  to  be  handed  off  to  track  750.  See  Figure  8. 

•  Scenario  2:  Overlapping  radar  coverage  (772  and  774)  and  ADS  coverage  (Track  773)  on  a 
single  vessel.  Track  773  is  the  first  to  acquire  the  vessel  but  hands  it  off  to  track  772,  once 
772  acquires  the  track  due  to  its  superior  status.  Track  774  then  acquires  track  and  takes  a 
hand  off  from  772  due  to  774’s  superior  status.  See  Figure  9. 

•  Scenario  3:  Overlapping  radar  and  ADS  coverage  on  multiple  tracks  over  an  extended 
period.  This  demonstrates  the  algorithm’s  ability  to  handle  many  tracks  and  the  potential 
for  a  much  less  cluttered  display.  See  Figure  10. 

Several  other  scenarios  were  examined,  and  the  algorithm  performed  well  in  all  cases.  In 
summary,  the  algorithm  fused  all  tracks  that  were  in  the  overlap  region  that  met  the  fusion  criteria. 
It  would  change  reporting  responsibility  for  a  track  to  the  next  inferior  sensor  if  the  superior  sensor 
ceased  reporting.  The  algorithm  would  change  reporting  responsibility  for  a  track  to  a  more 
superior  sensor  if  that  sensor  started  to  report  on  a  vessel  which  was  currently  assigned  to  a  less 
capable  sensor.  It  had  no  trouble  with  crossing  or  passing  situations.  Marginal  situations  were  easy 
to  discriminate  as  the  algorithm  would  defuse  immediately  upon  failure  of  the  fusion  criteria. 

The  key  observations  to  be  made  are  the  affects  that  the  individual  membership  functions  had 
on  the  results.  If  the  membership  function  was  not  sufficiently  broad  enough  the  decision  to  fuse 
two  tracks  was  not  made.  This  is  particularly  true  for  the  course  membership  function.  Vessels  that 
are  going  extremely  slow  and  or  turning  tend  to  have  widely  varying  headings  from  the  radar 
reports.  The  addition  of  fusion  parameters,  such  as  size  and  track  quality,  would  certainly  provide  a 
greater  degree  of  confidence  in  situations  where  position,  course  and  speed  are  very  close.  While 
the  data  collected  did  not  contain  this  type  of  situation,  it  is  reasonable  to  assume  that  this  scenario 
is  common  in  the  busy  harbors  and  waterways  under  the  USCG  management .  These  findings  are 
consistent  with  the  simulated  overlapping  radar  results  reported  in  [Ref.  2]. 
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Figure  10.  Overlapping  Radar  and  ADS  Coverage  on  Multiple  Tracks:  (a)  no  fusion 
applied  and  (b)  fusion  applied 
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6.  CONCLUSIONS 

This  report  presented  an  algorithm  to  fuse  redundant  observations  due  to  multiple  sensor  (type 
and  location)  coverage  in  order  to  provide  a  significant  reduction  in  duplicate  track  information 
provided  to  the  Vessel  Traffic  Services  (VTS)  operator  displays.  The  algorithm  accepts  inputs  from 
multiple  sensors  (radar,  ADS,  SR).  The  algorithm  was  tested  with  real  data  collected  from  the  VTS 
system  at  Puget  Sound  in  September  1996.  The  tests  showed  that  the  algorithm  correctly  fuses 
redundant  sensor  observations  on  the  same  vessel. 

The  algorithm’s  current  performance  is  limited  by  the  number  of  attributes  that  could  be  used  to 
determine  association.  Only  Latitude,  Longitude,  Course  and  Speed  were  adopted  to  determine  a 
level  of  “sameness”  between  vessels.  The  Course  attribute  is  not  reported  with  reasonable  accuracy 
by  radar  when  vessels  are  turning  at  reasonable  speeds. 

The  performance  of  the  algorithm  can  be  enhanced  by  adding  other  attributes  from  which 
measures  of  similarity  could  be  determined.  The  membership  function  design  needs  to  be  validated 
by  statistical  methods  once  large  and  varied  data  sets  are  available.  This  will  optimize  the  design  of 
the  membership  function  for  a  given  sensor  and  sensor  suite  within  the  applicable  VTS  System. 
Once  these  membership  functions  are  validated  for  each  type  of  sensor,  the  algorithm  could  be 
made  adaptive.  Also,  the  membership  function  shape  can  be  adapted  not  only  to  the  sensor  type  but 
also  to  statistics  of  the  data. 
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